|
04.06.2026 15:00 Uhr |
Über diesen Gedanken bin ich – und wahrscheinlich viele andere auch – schon gestolpert. Mocks bieten hier auf den ersten Blick eine einfache Lösung: Man muss nur die relevanten Methodenaufrufe simulieren, man kann relativ schnell einen Test schreiben und eine hohe Testabdeckung erreichen. Jedoch liegt hier der Ursprung des Problems.
Ein Use-Case in einer Business-Applikation besteht nur selten aus einem atomar programmierten Stück, wie ein Sortierungsalgorithmus, sondern vielmehr aus einem Ablauf von mehreren Schritten, die in verschiedenen Komponenten stattfinden.
Es wird ein Fehler aus der Produktion gemeldet, aber alle Tests sind grün? Oder Refactorings werden durchgeführt und zwingen dazu, gleichzeitig auch die Tests großflächig umzubauen – sodass am Ende unklar bleibt, ob das Refactoring überhaupt fehlerfrei war? Solche Situationen deuten oft auf Tests mit starker Verwendung von Mocks hin. Ob und wie man auf Mocks in Backend-Tests von Business-Applikationen verzichten kann, welche Vorteile das mit sich bringt und wie sich trotzdem gut strukturierte Tests umsetzen lassen, zeigt dieser Artikel anhand eines konkreten Projektbeispiels.
Der Einsatz von Mockito sorgt dann dafür, dass die Tests von der Realität abgekoppelt werden. Es entsteht eine Diskrepanz zwischen dem, was die Tests abbilden, und dem tatsächlichen Verhalten der Anwendung.